Atari Mega Archive 1/Atari Mega Archive - Volume 1.iso/lists/gem/l_1199/1062

Internet Message Format | 1994-08-27 | 7.6 KB

From: [e-mail] (Mark Baker)
Date: 24 Jul 94  11:10:10
Message-Id: <UUCP.775073466@mettav>
Subject: Digest
To: [e-mail] ([e-mail])
Precedence: bulk

I'm afraid this is rather a long digest - my mail feed has been down for a few
days and I've just got about 200 messages all at once :)

Ofir:
 >> Question: How does ST-Guide handle displaying help if the user selects a
 >> help button inside a dialog?
 >
 > Answer: It doesn't, because your dialog called wind_update().

Correct answer: It works perfectly - you do use non-modal dialogues don't you?
:)

Warwick:
 > However, people are only just starting to multitask on the Atari.  Now
 > is the time to get things `right'. There is still hope.  Imagine a
 > system where an application would co-operate with other applications to
 > pass keyboard events to the window under the mouse, or some other
 > focussing scheme (GEM treats focus==top, in the hope that it is far
 > more efficient to update a top window, but in reality, this is not the
 > case [I've done timing on it*]).  Of course, I'd never get 10% of you to
 > agree... and that's okay.

Why would you want keyboard events to go to a window under the top, if you've
got to click to set the focus, why not top as well. If you don't have to click
to set the focus (eg. under the mouse) the system is unusable as you can easily
end up typing in the wrong window.

Timothy:
 > We're saying to stop using dialogs.
 >
 > Ok... you just threw away part of the OS and told peope to replace it
 > with their own code (or a library).

The extra code is fairly minimal - wait for events, if it's a keyboard event
and the top window is your dialogue, call objc_find, form_keybd and objc_edit.
If it's a button event, use wind_find and if it returns your dialogue call
objc_find, form_button and if necessary objc_draw. Very little extra code. The
FLDLIB library (a simple lib that does little more than I described) is about
4k.

Steven:
 > With all this talk of GUI libraries how about porting (or reimplementing
 > a cut down version of) a multi-platform GUI library on top of GEM
 > that would give an API usable on Win32/System7/X platforms.
 > It's not that I don't like GEM, it's just that I'm looking to the day
 > when Ataris are no more and I have to move my source to a
 > Clown/PowerPC/Unix box...

There are multiplatform libraries, but unfortunately none support the atari. If
you were to write one you would have to make it flexible enough that a program
could use entirely it's calls (and ISO C library calls) and no normal
aes/vdi/gemdos/bios/xbios calls.

The other problem with this type of library is that they are limited to
supporting the `lowest common denominator' of the systems they support. They
cannot support extra features of one that do not exist on others. Also some
GUIs like mswindoze have one window per app (not necessarily, but by
convention), menus in windows and horrible submenus. The atari and the mac have
multiple windows and a menu at the top of the screen. Writing a library so apps
behave naturally in both is difficult, for example in an mswindows drawing
program you would have a window with the toolbox and menu bar and sub windows
with files in, whereas on the atari you would have a separate toolbar window.
OTOH if an app only supports one window it would not use subwindows under
mswindows.

Mark-Oliver:
 > I thought there IS a program which patched MultiTOS to do all (even in
 > the desktop!) dialogs in windows!

It's called Multidialogue or something (multdial.prg IIRC) and it puts all
dialogues in windows, so they are app modal. It should work with Geneva and
MagiC as well - it works on single-tasking versions, where it lets you use
accs.

Ofir:
[dialogues in window]
 >> Errr... What happens if you run out of windows?
 >
 > You display a dialog of course. Not much else yu can do. However, with
 > MTOS, Geneva, Magic and WinX this problem is less crucial.

And without them it is unlikely to occur.

???:
 > The lower-level support is that a dialogue can be modal for its own
 > application, but allows you to switch to other applications.  This
 > COULD be provided by OS extension for existing apps.  eg when an app
 > puts up a modal dialogue (from its own point of view), the OS still gives
 > access to OTHER apps, but does not give access to other windows of that
 > app. I think this can be done transparently to old code, and gives us what
 > we really want.  (It would be nice if I can start editing another
 > document while printing from Calamus, say. But it's not the end of the
 > world if Calamus is blocked out while printing, but I can switch to another
 > app to get on with something else).

This is what you get with multidialogue. As for calamus letting you print and
edit simultaneously this would definitely require calamus to be partly
rewritten and for reasonable performance you really need multithreading which
is sort of possible under MiNT.

Julian:
 > Really? What about objc_edit() which can't clip to a rectangle list?

But no problem if you only allow top windows to be used, as is standard on the
atari.

Dan:
 >> GEM is not going to change to match my philosophy; so we're writing a
 >> GEM Library to *match* the philosophy. There is no reason why users have
 >> to be stuck in the dark ages in terms of a user interface.
 >> I'm not sure I understand your emphasis?  Match -what-?  The GEM
 >> philosophy (topped windows and all the other stuff you hate but is
 >> standard) or your own philosophy?  Coud you be more clear on this.
 >
 > My philosophy : I want a *consistent*, *intuitive*, *easy to use*, *easy
 > to program* GUI that is powerful and fast. Currently GEM is *none* of
 > these.

If you allow clicks in background windows then it will not be consistent with
other applications. Topping windows on all clicks in them may not be desirable
but it _is_ consistent with existing GEM programs and with programs for the mac
and mswindows. As for intuitive, since keystrokes obviously go to the top
window only, why not buttons. It isn't intuitive if button events sometimes top
a window and sometimes activate a button depending on where they are. I can't
see anything wrong with GEM on the ease of use front and as for ease of
programming - it's pretty bad, but have you tried mswindows?

Christian:
 >

Looks like Ofir started a trend :)

Joe:
 > If you donate ANY amount for your own use and Holger will be delighted!
 > Anyone can include it for FREE with their software BUT
 > *I'm* suggesting (like Andre) that developers might like to give more
 > than the minimum donation since if you've gone to the trouble of creating
 > a hypertext you're certainly making considerable use of it. *I* would be
 > dissappointed to see developers taking the attitude that they're doing
 > their bit by supporting ST-Guide in the first place it's a valid POV but
 > not mine!

Certainly commercial software developers should pay, freeware authors should
not be forced to pay but treated as end users. I will be paying at least the
minimum but if I were forced to then I would not support it at all.

Dan:
 > I've used MTOS enough to be disgusted with it. It's a piece of crap. Slow,
 > and inefficient.

Which version? I've seen the first 4.1 beta and it is almost as fast as single
tasking versions of TOS, although it doesn't work properly on the falcon.
Apparently the second beta is faster still.

 > WinLIB PRO supports all MTOS messages, and with WinX and normal TOS we
 > can support almost all the AES 4.* stuff, and do it *faster* -- without
 > having the overhead of dragging MiNT along with us when it's not needed.

There is almost no overhead due to MiNT. On average the slowdown is negligible
and many things such as memory allocation are a bit faster.